Remarks : 



Reconsideration of the application is respectfully requested. 

Claims 1-10 are presently pending in the application. No 
claims have been amended or canceled. 

In item 2 of the above- identified Office Action, claims 1-10 
were rejected under 35 U.S.C. § 102(e) as allegedly being 
anticipated by U. S. Patent No. 6,757,256 to Anandakumar et al 
("ANANDAKUMAR") . 

Applicants respectfully traverse the above rejections. 

I. Applicants' claims all require, among other limitations, 
"first data with real-time requirement" and "second data 
without real-time requirement". 

Applicants 1 independent claims 1 and 8 require, among other 
limitations, the transmission of "first data with real-time 
requirement" and "second data without real-time requirement". 

Applicants 1 claim 10 incorporates all of the limitations of 
claim 8, therein. 

The instant application contrasts "data with real-time 
requirement" with "data without real-time requirement", on 

page 3 of the instant application, line 17 - page 4, line 12, 
as follows: 
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"In the case of multimedia data to be transmitted, a 
distinction must be made between data to be transmitted 
in a case of which, in particular, a very high demand 
must be made that it can be guaranteed, that the delay 
time between the data is very short as is the case, for 
example, with voice data or video data. In the case of 
voice data, it is particularly important that the voice 
data transmitted are received at the receiving computer 
with very little delay since otherwise the quality of 
the received reconstructed voice data is considerably 
reduced for the user of the receiving computer who 
listens to the reconstructed voice data. In 
particular, such requirements will also be called real- 
time requirements of the data in the text which 
follows . 

In contrast, a usual multimedia data stream also 
contains second data without real-time requirements , 
for example text data or also still-image data. 

In the case of such data, it is only generally 
important that the data are transmitted as free of 
errors as possible but not necessarily that, for 
example, the delay of the transmission between the 
individual data elements is as short as possible . 



See also, page 9 of the instant application, line 25, through 
page 10, line 18. As such, as defined in the instant 
application, "data with real-time requirement " is a particular 
type of data, in particular, in which a "very high demand must 
be made that it can be guaranteed, that the delay time between 
the data is very short as is the case, for example, with voice 
data or video data". The specification of the instant 
application defines "data without real-time requirement " as a 
different type of data, in which "it is only generally 
important that the data are transmitted as free of errors as 
possible but not necessarily that, for example, the delay of 
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the transmission between the individual data elements is as 
short as possible". 

Thus, Applicants 1 claimed "first data with real-time 
requirement 11 actually comprises a different category of data 
(i.e., data of a different type, such as voice data vs. text 
data) than Applicants 1 claimed "second data without real-time 
requirement " . The difference between Applicants' claimed 
first and second data types is not that on data is transmitted 
in real-time, and the other is not, but that the first type of 
data is of a type with a real-time requirement (i.e., urgency) 
and the second type of data is of a type without a real-time 
requirement (i.e., no urgency) . Resending packets of data 
with a real-time requirement (i.e., resending lost packets) at 
a different time, does not change those packets " with real- 
time requirement" into data packets " without real-time 
requirement" (i.e., a whole different type of data, such as 
voice vs. text) . 

II. Contrary to the statement made in the Office Action, 
ANDAKUMAR does not teach or suggest, among other 
limitations of Applicants' claims, the transmission of 
Applicants' claimed "second data without real-time 
requirement " . 

As stated in Applicants 1 previous response, the ANANDAKUMAR 
reference discloses a process for sending real-time 
information (i.e., information with real-time requirements). 
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See the title, the Abstract, line 1, also, column 2, lines 10 
- 14, column 3, lines 66-67 and elsewhere. The ANANDAKUMAR 
reference does not teach or suggest transmitting data without 
a real-time requirement , as required by Applicants 1 claims. 



In response to Applicants 1 previous arguments that ANDAKUMAR 
does not disclose transmitting data without real-time 
requirement , it was alleged on pages 6-7 of the Office Action: 

"In response to A) Anandakumar teaches a method of 
sending packets of real-time information at a sender 
includes steps of initially generating at the sender 
the packets of real-time information with a source rate 
greater than zero kilobits per second, and a time or 
path or combined time/path diversity rate. When the 
QoS is on an unacceptable side of said threshold 
increases the diversity rate and sends not only 
additional ones of the packets of real-time information 
but also sends diversity packets at the diversity rate 
as increased (see abstract) . Anandakumar teaches the 
method sends real time packets and diversity packets 
where the diversity packets are packets that were lost 
and are retransmitted at a later time because the 1 real 
time packets were lost 1 . Therefore the diversity 
packets are considered to be non-real time packets 
since the diversity packets are a retransmission of 
real-time packets. There is no limitation in the claim 
on what differs a real time packet from a non-real time 
packet or the transmission times of the packets and 
therefore the real time packets and the diversity 
packets taught by Anandakumar meets the scope of the 
claimed limitation 'transmitting first data with real- 
time requirement and a plurality of second quality of 
service classes in the application layer for 
transmitting second data without real-time 
requirement 1 . 11 [emphasis added by Applicants] 

Applicants respectfully disagree. ANDAKUMAR only discloses 
sending packets of real-time information. Thus, ANDAKUMAR 
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only teaches transmitting data with real-time requirements. 
For example, col. 3 of ANDAKUMAR, line 66 - col. 4, line 13, 
states : 



"In one form of the invention, a process of sending 
packets of real-time information at a sender includes 
steps of initially generating at the sender the packets 
of real-time information with a source rate greater 
than zero kilobits per second, and a time or path or 
combined time/path diversity rate, the amount of 
diversity initially being at least zero kilobits per 
second. The process sends the packets, thereby 
resulting in a quality of service QoS, and optionally 
obtains at the sender a measure of the QoS. Another 
step compares the QoS with a threshold of 
acceptability, and when the QoS is on an unacceptable 
side of said threshold increases the diversity rate a nd 
sends not only additional ones of the packets of real- 
time information but also sends diversity packets at 
the diversity rate as increased. Also, rate/diversity 
adaptation decision may be performed at receiver. 11 
[emphasis added by Applicants] 

The diversity packets of ANANDAKUMAR are described in col. 8 
of ANANDAKUMAR, lines 31 - 33, which states: 

"'Diversity packet, ' where the term is used herein 
sometimes means a self-contained packet with its own 
header and diversity information. However, the term 

■diversity packet 1 can also mean diversity bits and 
extra header bits put in a packet that already has a 
header and a payload. 11 [emphasis added by Applicants] 

In ANANDAKUMAR, there are two types of diversity information: 
a) time diversity; and b) path diversity. Time diversity and 
path diversity packets are summarized in col. 8 of 
ANANDAKUMAR, lines 20-27, which states: 
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"In time diversity, information about packet n is also 
transmitted in packet n+1 and sometimes in even further 
packets where packets having at least some information 
in common with each other are called dependent packets. 

Path Diversity sends dependent packets over two or more 
paths in the network , thus increasing the probability 
of recovering the information that was coded to produce 
the dependent packets." [emphasis added by Applicants] 

Clearly, the diversity packets of ANANDAKUMAR are still 
packets of data with a real-time requirement , only shifted in 
time or path. As stated above, resending at a different time, 
packets of "data with a real-time requirement" (i.e., voice 
data, which has a real-time requirement) does not convert the 
data into "data without a real-time requirement" (i.e., a 
whole different type of data, such as text, which does not 
have a "real-time requirement"). 

The "diversity packets 11 of ANANDAKUMAR are understood to be 
packets of real-time data having headers and information, 
which were determined to be previously transmitted below a 
threshold of acceptability. In ANANDAKUMAR, "time diversity" 
is the retransmission of lost packets at later moments in time 
(i.e., information about packet n is also transmitted in 
packet n+1) , whereas, "frequency diversity" or "path 
diversity" is the retransmission of lost packets on different 
frequencies or paths. However, r egardless of which type , time 
or rate, a diversity packet is a retransmitted packet of the 
original real-time data thus, is data with a real-time 
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requirement . Thus, in ANAND AKUMAR , "diversity packets" formed 
from original packets of data with real-time requirement, are, 
themselves, merely retransmitted packets of data with real- 
time requirement . Changing the diversity requirements for the 
retransmission of real-time packets does not change the type 
of the data (i.e., does not convert the data into data without 
real-time requirement ) . In fact, the ANAND AKUMAR reference 
fails to teach or suggest the transmission of Applicants 1 
claimed "second data without real-time requirement". 

III. Applicants' claims all require, among other limitations, 
"a plurality of first quality of service classes" for 
transmitting the "first data" and "a plurality of second 
quality of service classes" for transmitting the "second 
data" and a "combined quality of service class formed 
from the first quality of service classes and the second 
quality of service classes". 

Additionally, Applicants 1 independent claims 1 and 8 recite, 
among other limitations, "a plurality of first quality of 
service classes" for transmitting the "first data" and "a 
plurality of second quality of service classes" for 
transmitting the "second data". 

Further, Applicants' independent claims 1 and 8 require, among 
other limitations, "a combined quality of service class formed 
from the first quality of service classes and the second 
quality of service classes". Page 11 of the instant 
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application, line 1 - page 12, line 18 describes the combined 
quality of service class 



Further yet, Applicants' independent claim 1 recites, among 
other limitations , 

" supplying the first data and the second data and the 
transmission parameters of the selected combined 
quality of service class to a unit of a transport 
layer, and transmitting the first data and the second 
data with the unit taking into consideration the 
transmission parameters . 11 [emphasis added by 
Applicants] 

Similarly, independent claim 8 recites, among other 
limitations , 

" a transmission unit of a transport layer receiving 
from said processor the first data and the second data 
and the transmission parameters of the selected 
combined quality of service class, and transmitting the 
first data and the second data taking into 
consideration the transmission parameters . " emphasis 
added by Applicants] 

As noted above, Applicants 1 claim 10 incorporates all of the 
features of Applicants 1 claim 8. 



IV. ANDAKUMAR does not teach or suggest, among other 

limitations of Applicants' claims, "a plurality of second 
quality of service classes" for transmitting the "second 
data" and a "combined quality of service class formed 
from the first quality of service classes and the second 
quality of service classes". 
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As stated above in section II, incorporated herein by- 
reference, ANANDAKUMAR neither teaches, nor suggests, 
transmitting "second data without real-time requirement", as 
required by Applicants 1 claims. 

In not teaching or suggesting transmission of Applicants' 
claimed "second data 1 ', ANANDAKUMAR additionally fails to teach 
or suggest "a plurality of second quality of service classes" 
for transmitting the "second data". Additionally, as 
ANANDAKUMAR fails to teach or suggest the claimed "second 
quality of service classes", ANANDAKUMAR, resultantly, also 
must fail to teach Applicants' particularly claimed "combined 
quality of service class". 

As ANANDAKUMAR fails to teach or suggest Applicants 1 claimed 
"second data" and "combined quality of service class", 
ANANDAKUMAR must also fail to teach or suggest Applicants' 
particularly claimed "unit"/" transmission unit". 

With regard to the arguments made by Applicants' in the 
previous response, that ANDAKUMAR does not teach or suggest a 
combined quality of service class, the Office Action states on 
page 7 , that : 

"In response to B) Anandakumar teaches the packets are 
transmitted at a rate where the rate is compared to a 
threshold rate set by the user. If the transmission 
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rate is greater than the threshold, then the packets 
are transmitted, otherwise the rate is increased to 
meet the required threshold. The transmission rate is 
considered to be the first quality of service and 
threshold is considered to be the second QOS w here the 
transmission rate and the threshold are combined to 
determine whether the packets can be transmitted or not 
(see abstract) . There is no limitation on the content 
or rules used to determine the quality of service and 
therefore Anandakumar meets the scope of the claimed 
limitation "the first data and the second data and the 
transmission parameters of the selected combined 
quality of service class to a unit of a transport 
layer." [emphasis added by Applicants] 

Applicants 1 respectfully disagree with the statements made in 
the Office Action. As shown above, ANANDAKUMAR compares the 
QoS with a threshold of acceptability. If the QoS is 
unacceptable, compared to the threshold, the diversity rate 
will be increased, by the QoS won't be changed. See 
ANANDAKUMAR, col. 4, lines 5-13. Thus, only the diversity 
rate is changed. Therefore there is only one QoS for all 
packets in ANANDAKUMAR. A combined quality of service class 
formed from the first quality of service class and second 
quality of service classes, as required by the claimed 
invention, is neither taught, nor suggested by ANANDAKUMAR. 



Further, the threshold of ANANDAKUMAR cannot correlate to 
Applicants 1 claimed plurality of second quality of service 
classes, because it does not relate to Applicants 1 second 
"data without real-time requirement", which is neither taught, 
nor suggested in ANANDAKUMAR. As such, ANANDAKUMAR fails to 
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teach or suggest, among other limitations of Applicants' 
claims, the claimed "plurality of second quality of service 
classes" 

In fact, the ANANDAKUMAR reference actually teaches away from 
Applicants' second quality of service class, and thus the 
combined service class, by only teaching the use of data with 
real-time requirements (i.e., real-time packets). 

V. Conclusion. 

Applicants 1 claims are believed patentable over ANANDAKUMAR, 
because, ANANDAKUMAR fails to teach or suggest, among other 
things, Applicants' claimed "second data without real-time 
requirement", "a plurality of second quality of service 
classes" for transmitting "second data without real-time 
requirement", "a combined quality of service class formed from 
the first quality of service classes and the second quality of 
service classes" and Applicants' particularly claimed 
"unit "/"transmission unit". 

It is accordingly believed that none of the references, 
whether taken alone or in any combination, teach or suggest 
the features of claims 1, 8 and 10. Claims 1, 8 and 10 are, 
therefore, believed to be patentable over the art. The 
dependent claims are believed to be patentable as well because 
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they all are ultimately dependent on claims 1 or 8. As it is 
believed that the claims were patentable over the cited art in 
their original form, the claims have not been amended to 
overcome the references. 

In view of the foregoing, reconsideration and allowance of 
claims 1-10 are solicited. 

In the event the Examiner should still find any of the claims 
to be unpatentable, counsel would appreciate receiving a 
telephone call so that, if possible, patentable language can 
be worked out. In the alternative, the entry of the amendment 
is requested, as it is believed to place the application in 
better condition for appeal, without requiring extension of 
the field of search. 

If an extension of time for this paper is required, petition 
for extension is herewith made. 

Please charge any fees that might be due with respect to 
Sections 1.16 and 1.17 to the Deposit Account of Lerner and 
Greenberg, P. A., No. 12-1099. 
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Respectfully submitted, 



KPS : cgm 

May 11, 2005 

Lerner and Greenberg, P. A. 
Post Office Box 2480 
Hollywood, FL 33022-2480 
Tel: (954) 925-1100 
Fax: (954) 925-1101 




Kerry P. Sisselman 
Reg. No. 37,237 
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